home *** CD-ROM | disk | FTP | other *** search
/ Kirk's Comm Disc 1995 December / Kirk's Comm Disc - Version 2.iso / dos / fido / ftsc_all.z43 / FSC-0048.001 < prev    next >
Text File  |  1990-06-17  |  14KB  |  311 lines
  1. Document: FSC-0048
  2. Version:  001
  3. Date:     17-Jun-90
  4.  
  5.  
  6.  
  7.  
  8.  
  9.                    A Proposed Type-2 Packet Extension
  10.                       Jan Vroonhof
  11.                            2:281/1.12@fidonet
  12.                              June 17,  1990
  13.  
  14.  
  15.  
  16.  
  17.  
  18. Status of this document:
  19.  
  20.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  21.      and requests discussion and suggestions for improvements.
  22.      Distribution of this document is unlimited.
  23.  
  24.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  25.      Software.
  26.                 
  27.                  
  28.  
  29. Purpose
  30.  
  31. The final goal of this document is to become a widely used
  32. standardised extension to FTS-0001 like FTS-0006,0007 and 0008 are and
  33. provide and elegant way for switching to to a new bundling method
  34. without requiring major effort or breaking anything.
  35.  
  36. ===============
  37.  
  38. Prolog
  39.  
  40. The main thing that needs stressing is that the additions covered by this
  41. document are FULLY (I repeat FULLY) BACKWARDS COMPATIBLE with FTS-0001
  42. (and other existing standards and practices in FidoNet and
  43. WhatEverOtherNets that I know of) in the sense that problems, that it
  44. still would create (e.g. zoneconflicts when dealing with a non
  45. compliant system) are already in the current system (FTS-0001). In
  46. short it it only correct some flaws in FTS-0001 WHITOUT generating new
  47. ones.
  48.  
  49. In this Document I have tried to stay as much as possible on the paths
  50. of extisting practices. Therefor I think implementing the additions it
  51. proposes will not be to hard.
  52.  
  53. ===============
  54.  
  55.  
  56. My thoughts about FSC-0039 and FST-0001 rev 12.
  57.  
  58. The revision 12 of FTS-0001 introduced the term "(some impls)" to indicate
  59. that the some implementations used their own extensions to FTS-0001.
  60. The problem with this is that this info cannot be relied upon because
  61. there is no way to actually validate the data. One can only check
  62. wether these fields' values are in the range of valid values and hope
  63. for the best.
  64.  
  65. Secondly FSC-0039 introduced the idea of having a bitfield (called the
  66. capability word) indicating wether extension data was valid and also
  67. supporting indicating the ability to support other non type 2
  68. packets, thus allowing for flexible migration towards type 3.
  69. It also documented the adression extension used by various programs.
  70.  
  71. However FSC-0039 has two flaws:
  72.  
  73. 1. One cannot be sure the bitfield is zero because other
  74.    implementations might use this field for there own purposes.
  75.    Therefor this document includes a second validation copy for the
  76.    Capability Word (CW hereafter). This copy allows the FSC-xxxx
  77.    compliant software to validate the CW by comparing the two. The
  78.    change of some junk portraiting itself as a CW is therefor
  79.    significantly reduced.
  80. 2. Although FSC-0039 provides a way to make packet headers 4D it is
  81.    not backwards compatible. It there for cannot be used in FTS-0001
  82.    sessions to unknown systems. Therefor FidoNet is still not
  83.    totally 4D capabable. This is because while it implements fields
  84.    for zone and pointnumber, a FTS-0001 compliant application is not
  85.    required to look at these fields.
  86.    When a point mails using these fields to implement it's 4D
  87.    adress, a system only looking at the net/node info, as is required
  88.    by FTS-0001 still sees it as it's bossnode, bringing about the
  89.    obvious problems.
  90.    This document provides a way for transparant pointhandling, making
  91.    use of a technique already exploited by many mailers internally.
  92.    This will allow for this document to be implemented and used to
  93.    mailers not supporting it, while the danger that you are detected
  94.    as the bossnode is eleminated.
  95.    It does NOT provide full interzone backwards compatability but that
  96.    is not needed as badly while problems are not yet that bad. Any
  97.    measures to ensure backwards compatability on this side might harm
  98.    communciations with non supporting system when the old system could
  99.    handle the situation.
  100.  
  101.  
  102. | indicates extensions made by FTS-0001 rev 12 and
  103. : those made by this document and FSC-0039.
  104.  
  105.                                 Packet Header
  106.        Offset
  107.       dec hex
  108.               .-----------------------------------------------.
  109.         0   0 | origNode (low order)  | origNode (high order) |
  110.               +-----------------------+-----------------------+
  111.         2   2 | destNode (low order)  | destNode (high order) |
  112.               +-----------------------+-----------------------+
  113.         4   4 |   year (low order)    |   year (high order)   |
  114.               +-----------------------+-----------------------+
  115.         6   6 |  month (low order)    |  month (high order)   |
  116.               +-----------------------+-----------------------+
  117.         8   8 |   day (low order)     |   day (high order)    |
  118.               +-----------------------+-----------------------+
  119.        10   A |   hour (low order)    |   hour (high order)   |
  120.               +-----------------------+-----------------------+
  121.        12   C |  minute (low order)   |  minute (high order)  |
  122.               +-----------------------+-----------------------+
  123.        14   E |  second (low order)   |  second (high order)  |
  124.               +-----------------------+-----------------------+
  125.        16  10 |   baud (low order)    |   baud (high order)   |
  126.               +-----------------------+-----------------------+
  127.        18  12 |    0     |     2      |    0      |    0      |
  128.               +-----------------------+-----------------------+
  129.        20  14 | origNet (low order)   | origNet (high order)  |
  130. :             |  Set to -1 if from point                      |
  131.               +-----------------------+-----------------------+
  132.        22  16 | destNet (low order)   | destNet (high order)  |
  133.               +-----------------------+-----------------------+
  134. |      24  18 | ProductCode (low ord) | Revision (Major)      |
  135. |             +-----------------------+-----------------------+
  136. |      26  1A |             password                          |
  137. |             |             8 bytes   null padded             |
  138. |             +-----------------------+-----------------------+
  139. |:     34  22 | origZone (low order)  | origzone (Highorder ) | }
  140. |             +-----------------------+-----------------------+ } As in
  141. |:     36  24 | DestZone (low order)  | DestZone (Highorder ) | } QMail
  142. :             +-----------------------+-----------------------+
  143. :      38  26 | AuxNet (low order)    | AuxNet (high order)   |
  144. :             +-----------------------+-----------------------+
  145. :      40  28 | CWvalidationCopy (hi) | CWvalidationCopy (low)|
  146. :             +-----------------------+-----------------------+
  147. :      42  2A | ProductCode (high ord)| Revision (Minor)      |
  148. :             +-----------------------+-----------------------+
  149. :      44  2C | CapabilWord (low ord) | CapabilWord (high ord)|
  150. :             +-----------------------+-----------------------+
  151. :      46  2E | origZone (low order)  | origzone (Highorder ) | }
  152. :             +-----------------------+-----------------------+ } As in
  153. :      48  30 | DestZone (High order) | DestZone (Highorder ) | } FD etc
  154. :             +-----------------------+-----------------------+
  155. :             +-----------------------+-----------------------+
  156. :      50  32 | origPoint(low order)  | origPoint(Highorder ) | }
  157. :             +-----------------------+-----------------------+ } As in
  158. :      52  34 | DestPoint(High order) | DestPoint(Highorder ) | } FD etc
  159. :             +-----------------------+-----------------------+
  160. :      54  46 |     Prod Specific Data                        |
  161. :             +                                               +
  162. :             |                  4 Bytes                      |
  163.               +-----------------------+-----------------------+
  164.        58  3A |                 zero or more                  |
  165.               ~                    packed                     ~
  166.               |                   messages                    |
  167.               +-----------------------+-----------------------+
  168.               |    0     |     0      |    0      |    0      |
  169.               `-----------------------------------------------'
  170.  
  171.  
  172.       Packet       = PacketHeader  { PakdMessage }  00H 00H
  173.  
  174.       PacketHeader = origNode   (* of packet, not of messages in packet *)
  175.                      destNode   (* of packet, not of messages in packet *)
  176.                      year       (* of packet creation, e.g. 1986 *)
  177.                      month      (* of packet creation, 0-11 for Jan-Dec *)
  178.                      day        (* of packet creation, 1-31 *)
  179.                      hour       (* of packet creation, 0-23 *)
  180.                      minute     (* of packet creation, 0-59 *)
  181.                      second     (* of packet creation, 0-59 *)
  182.                      baud       (* max baud rate of orig and dest *)
  183.                                                              PacketType (* old type-1 packets now obsolete *)
  184.                      origNet    (* of packet, not of messages in packet
  185.                                      set to -1 if orig=point    *)
  186.                      destNet    (* of packet, not of messages in packet *)
  187. +                    productCode Lo (* 0 for Fido, write to FTSC for others *)
  188. |+                   serialNo Maj (* binary serial number (otherwise null)*)
  189. |                    password   (* session pasword  (otherwise null)    *)
  190. |                    origZone   (* zone of pkt sender (otherwise null)  *)
  191. |                    destZone   (* zone of pkt receiver (otherwise null)*)
  192. |                    auxNet     (* contains Orignet if Origin is a point *)
  193. +                    CW validation copy (* Must be equal to CW to be valid *)
  194. +                    ProductCode Hi
  195. +                    revision Minor
  196. +                    origZone   (* zone of pkt sender (otherwise null)  *)
  197. +                    destZone   (* zone of pkt receiver (otherwise null)*)
  198. +                    ProdData   (* Product specific filler *)
  199.  
  200.  
  201. When the two copies of the CW match they can be asumed to valid and used.
  202.  
  203. Stone-Aged: Old FTS-0001
  204. Type-2+   :     ,,       + Changes indicated by | and : are valid
  205.  
  206.  
  207.    A Type-N Bundle will always advertise it's capabilities in the CW
  208.    regardless of the type being sent.  As shown in the below example,
  209.    it allows Type-N processors to automatically track the capability
  210.    of your system.  Again, in cases where a stone-age processor is
  211.    being used, this field will be ignored, and in the unusual event
  212.    that it is not ignored, and is somehow harmful to the far system,
  213.    the Type-N processor can be configured to send a CW of 0.
  214.  
  215. The format of the Capability Word is designed to support up to 15 future
  216. bundle types, and is bit-mapped to facilitate the easy determination of
  217. the maximum common level supported between two nodes:
  218.  
  219.                msb           Capability Word               lsb
  220. Node Supports  ------------FTSC Type Supported **)------------
  221.  
  222.                 * 16 15 14 13 12 11 10  9  8  7  6  5  4  3 2+
  223.  
  224. 2+,3, and 7     0  0  0  0  0  0  0  0  0  0  1  0  0  0  1  1
  225. 2+,3, and 5     0  0  0  0  0  0  0  0  0  0  0  0  1  0  1  1
  226. 2+(this Doc )   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  1
  227. Stone Age       0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  228.  
  229.                 * - reserved for future use
  230.                 ** - Example bit definitions only 2 is and Stone-Age
  231.                      defined now. The rest are to be concidered
  232.                      "reserved by FTSC".
  233.  
  234.  
  235. In this example, the Type-N bundler would AND the two words, obtaining a
  236. word expressing the Types which are in common to both systems.  The most
  237. significant Type will be used, by default, but note that this assumes that
  238. new bundling Types will be increasingly more efficient or in some way more
  239. beneficial.  Because this may not always be the case, there should be a
  240. method provided, as illustrated above, to override the automatic upgrade
  241. should this become the case.
  242.  
  243. Processing Type-2+ bundles:
  244.  
  245. Generating:
  246.  
  247.       Do we have a CW              Does CW indicate
  248.      stored for dest?  YES ---->   higher packets  YES ---> Generate higher
  249.            NO                       we support?                packet
  250.            |                            NO
  251.           \|/                           |
  252.            +-----<----------------------+
  253.            |
  254.       Fill header with all info
  255.            |
  256.           \|/
  257.            |
  258.       Are we sending from a point? (origPoint != 0) YES --+
  259.            |                                              |
  260.           NO                                              |
  261.            |                                             \|/
  262.            |                                    set AuxNet = OrigNet
  263.           \|/                                 Set OrigNet = -1
  264.            |                                              |
  265.            +-----<----------------------------------------+
  266.            |
  267.       Add Messages
  268.            |
  269.       Terminate packet
  270.            |
  271.        Send packet
  272.  
  273. Recieving:
  274.  
  275.        Recieve Packet
  276.            |
  277.        Packettype = 2  NO  -------------> Process Type-Other
  278.           YES
  279.            |
  280.            |
  281.        CWcopies match  NO --------+------> Treat as normal Stone-Age packet
  282.           YES                     |     |
  283.            |                      |     |
  284.        Store CW                  /|\    |
  285.            |                      |    /|\
  286.        CW is 0 YES  --------------+     |
  287.           NO                            |
  288.            |                            |
  289.            |                            |
  290.        CW indicates support for 2+ NO --+
  291.           YES
  292.            |
  293.            |
  294.        OrigPoint is 0  NO  ---------------+
  295.           YES                             |
  296.            |                             \|/
  297.           \|/                    Set OrigNet is Baud
  298.            |                              |
  299.            +------<-----------------------+
  300.            |
  301.         Process using added info
  302.  
  303.  
  304. Epilog
  305. ======
  306.  
  307. I'll be glad to get some feedback. You can put it in NET_DEV or
  308. netmail me.
  309.  
  310.                        Jan Vroonhof (2:281/1.12@fidonet)
  311.